Conversation
… the bound FFmpeg <= 7.1 converts 16-bit <> 10-bit by a plain shift of 6 in both directions, so the round trip is exact. FFmpeg 8.0 still encodes with the shift but decodes by 65535/1020, taking the legacy peak 255 << 2 as white, so the round trip gains 65535/65280 = 257/256. Rather than raising factor from 0.8 to 2.5, measure the gain by projection, assert that it is within 1% of unity, divide it out, and check the residual at the original factor = 0.8.
Closed
Contributor
Author
|
Unit tests pass on the fork's CI for head commit 32b00db (Python 3.10 and 3.x): https://github.com/hhoppe/mediapy/actions/runs/36083142253 |
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
test_video_read_write_10bitcurrently tolerates FFmpeg 8 by raisingfactorfrom 0.8 to 2.5, which leaves the residual error effectively unchecked.The mechanism: FFmpeg <= 7.1 converts 16-bit <> 10-bit by a plain shift of 6 in both directions, so the round trip is exact. FFmpeg 8.0 still encodes with the shift but decodes by 65535/1020, taking the legacy peak
255 << 2as white, so the round trip gains 65535/65280 = 257/256.This version measures that gain by projection, asserts it is within 1% of unity, divides it out, and then checks the residual at the original
factor = 0.8. It passes with FFmpeg 8.0.1; on FFmpeg <= 7.1 the gain is 1, so the test reduces to the original one.🤖 Generated with Claude Code